The typo correction is correct however it's worth pointing out that these constructs are heavily relying on description statements to describe the intent vs. formulating proper model restrictions to enforce existence of these list keys within a local NI context.

PR as-is LGTM but this modeling should be reworked as a subsequent issue as I'm noticing now.

It requires implementations to have to build special logic outside of the schema that can provide inconsistencies. This identityref allows for ANY protocol type to be referenced legally and any unbound string for the name. Maybe the grouping should not be so loose especially when there is only 1 current usage

Anything I can do to help it? I am implementer, and I needed this ambiguous point resolved. I would of course always welcome more clarity on the schema level, but for now correct description is better than nothing. I would prefer to keep an issue of matching against technically unbound space of potential protocol names separate.

That's why I said this LGTM as-is.... should not block this PR

I'd suggest proposing a separate PR to rework solving restrictions/relationships in the modeling vs. description stmts post this merge (as that will take slightly longer to likely come to consensus)

LGTM